Insurance and investment products are highly complex and technical products. For example, different insurance products have various features and options. The computer processing and mathematical calculations required for the various insurance products is enormously complicated. Thus, processing requests for information is a complex and often error prone activity.
In the insurance industry, insurance products are often sold by agents, working in the field. Typically, an agent will call on a prospective client (or "prospect") to discuss the insurance products that may interest a client. The agent often brings along statistical information prepared for a particular client to illustrate to the client the benefits of the various products that the agent wishes to sell. As is easily appreciated, the premiums paid and the resulting benefits received depend on many factors (such as, e.g., the age of the client, the number of dependents, the income of the client, the type of policy, the health of the client, etc.) However, due to the complex nature of the many differing insurance products, the agent cannot prepare statistics that illustrate the operation of each product for each contingency.
An insurance agent usually has access to a computer to help prepare statistics for a client, as well as for keeping records as to clients and appointments. Often, the agent has a laptop computer, and is able to take this computer to a client so as to calculate premiums and returns, and show graphs and statistics on the spot. An agent will usually wish to show the client many possible proposals, each having various information about a product, such as product and component level premiums, cash values, surrender values, dividend values, and benefit amounts.
Due to the complex nature of insurance products, and because each insurance product often requires different or unique information as input, it is often the case the user interface for each computer system to perform these tasks is different for each insurance product. Traditional request screens have been designed and developed "one field at a time". There is usually one request screen for each insurance product. Given the number of products and product variables, traditional request screens are often extremely complex. Because of the large number of products, and thus, the large number of request screens, it is difficult for users to learn and use current systems. In particular, it is often not easy for agents to learn and use the various computer user interfaces to produce information for clients.
Further, once the agent has made a sale, the agent usually fills in a form with the relevant client information (usually an insurance application, with the proposal selected by the client attached) and sends it to home office, where the information is entered into another computer system. At home office, a policy is "created" for the client. Based on this policy, the client and the agent are usually sent periodic statements from home office.
The processing of desired information to create sales proposals, for sales support, to issue a new product and for administrative situations is very difficult due to: (i) the large number of variations in products, their features or components, and the combinations of features that are packaged for a client, (ii) the calculations that are necessary to provide information about the products, and (iii) the variable assumptions that often are used to determine a policy's value (for example, an assumed amount of premium flow, the absence and presence of loan activity, policy dividend scales, interest earnings, and mortality experience).
As an example of a product with specific features, a base ordinary life insurance policy may be packaged with a disability rider, accidental death benefit, and a term rider that is made up of both term insurance and paid-up policy features. To support a given client's needs, an information quote must factor in and request all of the desired policy components and convey that information to calculation routines that determine the information that is either requested or required given the specific policy conditions necessitated by the quote. The process that performs the information quote must access required rates. Eventually, the quote and related information is returned to the requester.
Insurance product life-cycles span multiple years. This results in the need to provide not only point in time information but also information that spans a one or a number of time intervals. An example of point in time information is the value of a policy on a particular date. An example of information that spans one or a number of time intervals is a client's annual contribution. Often, a request by an agent, customer or actuary may involve projecting out twenty or more years into the future, interpreting existing information on a previously sold product, or projecting the impact on policy values if certain product assumptions are modified, as well as providing specific point in time information.
Additionally, based on an issued policy, information about a change in policy features may be requested. An example of such a request might be to provide information as to the premium level if the amount of insurance in force with the policy is reduced or a rider or benefit is added, modified or deleted.
The processing of desired information also requires complex calculations to demonstrate how attributes of these products and their underlying components will behave over time. In addition, these same product calculations may be required at many stages of a product's life cycle. For example, product values are often calculated during product development, at point of sale, at time of purchase or new issue, and at termination.
In the insurance industry, information is often required about a policy at a composite policy level and at a policy component level. An insurance policy typically has a core component and one or more riders that provide additional features for the policy. Thus, calculations that are performed must also provide information about the policy as a whole (including all the riders) and about the riders individually. As an example, it is often necessary to provide information on the cost of an ordinary life coverage, a death and disability rider, and a yearly renewable term rider in total as one policy or at the individual policy component level. As above, these values may change over the life time of the policy, and therefore, iterations of values over a number of time intervals (typically years) are also required.
Furthermore, variables impacting policy values, for example, types of underwriting, insured age, sex, issue state, product and component type, and the time interval requested, require access to complex rate structures that are utilized by information calculation routines. Rate information is determined by actuarial formulae and historical information about mortality, investment experience, and other factors.
In general, the parameters that are needed to compute information about a particular insurance product include the product and component types, the rates accessed for the time interval being requested, the age and sex of the insured, and the underwriting class.
New financial service products, introduced at a rapid pace to meet market demands and regulatory pressures, add another level of complexity. Deployment of these products requires the ability to calculate product values at a variety of points in the product development, sales, new issue and servicing cycle.
Part of the sales process typically utilizes complex calculations to demonstrate how attributes of insurance products and their underlying components will behave over time. In addition, these same product calculations are often undertaken at many stages of a product life cycle. For example, product values are calculated during product development, during the sales process, at time of purchase or issue, and at termination.
In many cases, a new product contains many similarities with those already existing in the portfolio. Differences may exist in the underlying funding mechanisms of the product while many other features are carried forward from existing products. In addition, existing products may require innovative changes to keep pace with the marketplace as new marketing opportunities are identified or as the interest rate climate changes. This effort may consist primarily of repackaging an existing product to present it in a new light or altering the dividend scale for a product.
A computer system used in processing information about insurance products must therefore address the highly complex and often slow interactions between the information request screens, calculation routines, and information display options, given the number of variables and large number of rates required to support typical information requests. Return of requested information should support "point in time" information, information across a number of time intervals, and should be accessible at a policy or policy component level. Finally, the system should be easily adaptable to modifications in and new products.
To deal with these complexities, complex computer based information request screens and numerous calculations routines are often developed and used by insurance companies and their agents. Typically, quotes are done on personal computers and administrative procedures are supported on large or mid-scale mainframe computers. Because of the different architectures of personal and mainframe computers, the development of multiple request screens and calculation routines in both architectures is typically required. Similarly, calculation routines are often separately developed for each type of product available. Therefore, a large number of often overlapping calculation routines are developed that do not take advantage of the functions and real world constraints common to most products. This results in additional expense when developing and maintaining these systems. Such a dual environment often results in inconsistent information being provided to a user.
The conventional response to these needs has been a proliferation of dedicated systems. The calculations performed by these systems often overlap, causing many redundancies. Updating conventional versions of these product calculation computer systems has historically been a bottleneck to releasing new products, particularly in the financial services industry.
More specifically, conventional software approaches have drawbacks in several areas. First, the structure of conventional systems is mostly attribute-oriented, rather than component-based. Each module of conventional systems is designed to perform a calculation, regardless of the product. For example, in conventional systems, a module that computes a cash value of a policy is usually designed to compute the cash value for all types of policies. When a new policy is added, this (and other) modules must be modified to accommodate the new policy. Updates resulting from product changes or innovations generally span many modules, rather than being localized.
Second, as explained above, in conventional systems, there is redundant code, since many of the insurance products have similar behaviors.
Third, the procedural-based code is littered with if/case statements that branch conditionally depending on the type of product. Writing and modifying such code is often quite error prone.
In addition, due to the lack of a common interface, versions of the product calculations exist in multiple existing software applications. These applications span hardware architectures and business areas. The development and maintenance of such duplicate applications is expensive and inefficient.
Therefore, known systems and methods for requesting information from a user as to an insurance product (for example, information so that an insurance policy can be designed for the user, or information to update or modify or provide information about an existing policy) and for performing calculations related to insurance products are entirely inadequate for the complexity and number of packaged product features and components. Existing systems can not easily provide information about various product options at varying points or time intervals. When new products are added to an insurance company's product line (or if existing products are modified), the computer systems used to sell and process such products can not easily be modified for the new products.
A uniform approach is needed, in which one user interface can be used to enter information about all possible products, and where the calculations that are performed are designed based on the operations that take place, not on the underlying product for which the operation is performed.